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REMARKS/ARGUMENTS 

In responding to the July 1, 2009 Office action, applicants respectfully request 
withdrawal of the rejections and reconsideration of the application in view of remarks 
contained herein. 

The following diagram illustrates the relationship among the pending claims, 
including independent claims 1 and 12. 




Rejections Under 35 U,S,C, § 102 

Independent claims 1 and 12 and dependent claims 2-3, 5, 7, 10, 14 and 16 stand 
rejected under 35 U.S.C. § 102(e) as being anticipated by Bajko (US AppUcation Publication 
20040196796). Applicants respectfully traverse the rejection. 

Bajko describes that a subscription can be associated with a plurality of public and 
private identities. In particular, Bajko describes the steps of storing, in a user information 
storage, information of the relationships between the identities and of a control entity in 
which at least one of the public and private identities is registered, and allocating the control 
entity to a further registration based on the information stored in the user information storage. 
See Bajko, abstract. 
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In rejecting independent claim 1, the Office action asserts that Bajko teaches every 
element of these claims and cites a number of portions of Bajko to support the rejection. 
Applicants have reviewed the cited portions and the remainders of Bajko and found no such 
teaching. 

In response to Applicants' previous arguments with respect to claim 1, the Office 
action points to Bajko, paragraphs [0017]-[0018], figures 2-3, and states that Bajko discloses 
"a HSS... returning to the S-CSCF a response message comprising the user's subscription 
information" recited in claim 1 . Applicants respectfully disagree and submit that: 

1) Bajko describes in paragraphs [0017]-[0018], "the S-CSCF selection is done in the 
I-CSCF during registration," "the I-CSCF is configured to decide whether newly registered 
identities are being addressed to a different S-CSCF" and "Thus it is possible that the 
independent registrations of the same subscription are forwarded to different S-CSCFs based 
on the server capability information received by the I-CSCF firom the home subscriber server 
(HSS)." From there, the Office action makes a conclusion that the information firom HSS is 
forwarded to S-CSCF. Applicants respectfully point out that paragraphs [0017]-[0018] of 
Bajko at best teach that the I-CSCF forwards the registrations of the same subscription to 
different S-CSCFs based on the information from the HSS. Further referring to figure 1 
which corresponds to paragraphs [00 17] -[00 18], Bajko apparently does not suggest that the 
HSS directly forwards information to the S-CSCF. 

2) The Office action further states that figure 2 of Bajko shows a connection between 
the HSS and the S-CSCF and thus concludes that the HSS forward the registration of the 
subscription to the S-CSCF. Fxirther, it can be seen that figure 2 shows three S-CSCFs (S- 
CSCFs 22, 23 and 24) where the HSS only connects with one (S-CSCF 23) of the three while 
figure 3 gives an example of signaling based on the network structure shown in figure 2. 
Paragraphs [0032]-[0033], which correspond to figures 2-3 of Bajko, suggests that S-CSCF 
22 is the one currently serving the user equipment which is to receive the registration of the 
user equipment. However, figures 2-3 do not suggest that S-CSCF 22 is connected with the 
HSS. 

Therefore, contrary to the Office action's characterization, Bajko fails to teach the 
claimed feature of "a HSS... returning to the S-CSCF a response message comprising the 
user's subscription information" recited in claim 1. 
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The Office action also points to Bajko, paragraphs [0033], and states that Bajko 
discloses the feature of "a HSS first storing the name of S-CECF" recited in claim 1. A 
review of Bajko shows that it merely suggest some functions of the Home Subscriber Server 
(HSS) such as storing information of identities of the user and a call control entity in which 
the user is registered. Bajko, however, fails to describe any specific implementation that 
allows the HSS receive a request message from the S~CSCF or any other call control entity 
and store the name of the S-CSCF in the request message upon receiving it. Therefore, Bajko 
fails to teach "Upon receiving a request message from Serving Call Session Control Function 
(S-CSCF) comprising a request for a storing name of the S-CSCF and for downloading a 
user's subscription information, a HSS first storing the name of S-CSCF in the request 
message" recited in claim 1 . 

The Office action also points to Bajko, paragraph [0037], and states that Bajko 
discloses the feature of "the HSS ... retuming to the S-CSCF a response message comprising 
the user's subscription information" as recited in claim 1. Bajko merely suggests the HSS 
retum the S-CSCF name in the response given for the user registration status query. Bajko, 
however, fails to teach the HSS returns the user's subscription information. Furthermore, as 
shown in figure 3, Bajko suggests the HSS 26 retum the response to the I-CSCF 31. It, 
however, does not teach retuming the response to the S-CSCF as recited in claim 1. The S- 
CSCF required by claim 1 should not be confused with the I-CSCF described by Bajko. 
Therefore, Bajko does not disclose or suggest "retuming to the S-CSCF a response message 
comprising the user's subscription information" as recited in claim 1. 

Furthermore, the Office action points to Bajko, paragraphs [0033], [0036], [0037] and 
[0040], and states that that Bajko describes the elements recited in claim 1. The applicants 
respectfiiUy disagree. 

Bajko recites in paragraph [0036] that the HSS "keeps a record of the relations 
between various identities associated with the subscription" and "maintains information 
regarding identities that are registered to the S-CSCFs," and that "in case of registration of a 
further identity related to an already existing registration, the same S-CSCF can be allocated 
for this registration by providing appropriate rooting information such as the name and/or 
address of the S-CSCF." In paragraph [0037] and figure 3, Bajko further describes that "the 
HSS may detect e.g. in the case of an initial registration of, for example, a public user identity 
(IMPU) whether any identities of the same user or subscription has already been registered" 
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and "in case of an existing registration the HSS shall return the S-CSCF name in the response 
given for the user registration status query." Bajko at best suggests that the HSS may allocate 
the same S-CSCF for registration of a further identity related to an already existing 
registration by providing the name of the S-CSCF. 

For the aforementioned reasons, the applicants submit that Bajko fails to anticipate 
independent claim 1 . 

In rejecting independent claim 12, the Office action asserts that Bajko teaches every 
element of the claim and cites a number of portions of Bajko to support the rejection. 
Applicants have reviewed the cited portions and the remainders of Bajko and foxmd no such 
teaching. In particular, the applicants respectfully point out that: 

1) The Office action points to Bajko, paragraphs [0036]-[0037], where it describes 
"if there is at least one Public User Identity of the UE requesting registration that has been 
registered in the HSS and the registration is still valid, and the HSS determines there is no 
need for the I-CSCF to re-select an S-CSCF to serve the UE, then said information needed for 
determining an S-CSCF comprises the name of the S-CSCF that is serving the UE," and 
paragraph [0036], where it describes "the HSS also maintains information regarding identities 
that are registered to the S-CSCFs." From there, the Office action then concludes the HSS 
described by Bajko stores information (i.e., name of the S-CSCF) that was used by the UE 
last time. However, "the information regarding identities that are registered to the S-CSCFs" 
described by Bajko should not be confused with the name of the S-CSCF. The former merely 
refers to the UE or subscription's identity registered to the S-CSCFs. (See Bajko, paragraph 
[0036] "individual identity (ID) registrations for a subscription are synchronized in a 3 GPP 
IMS (IP Multimedia Subsystem) domain by means of the HSS", and paragraph [0037] "the 
HSS may detect e.g. in the case of an initial registration of, for example, a public user identity 
(IMPU) whether any identities of the same user or subscription has already been registered"). 

The Office action further states that Bajko describes in paragraph [0037], "in the case 
of an existing registration the HSS shall retum the S-CSCF name in the response given for 
the user registration status query, instead of returning the server capabilities as is done in the 
prior art," and then concludes that there is no need for the I-CSCF to reselect an S-CSCF to 
serve the UE. Bajko, however, at best teaches a general function in an existing registration 
that the HSS returns the S-CSCF's name to the I-CSCF. It fails to teach a specific 
implementation as recited in claim 12, where the HSS retums the name of the S-CSCF 
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serving the UE to the I-CSCF when the HSS determines that the registration is still valid and 
there is no need for the I-CSCF to re-select an S-CSCF to serve the UE. 

For example, in a situation that the UE's previous registration to an S-CSCF is invalid 
or has expired, it is possible that the HSS does not have the name of the S-CSCF that the UE 
previously registered. Consequently, the solution proposed by Bajko can not be implemented. 
In contrast, the method recited in claim 12 considers whether the HSS still stores the name of 
the S-CSCF that has served the UE, where (i) when "the registration status is unregistered or 
the registration has expired, but the HSS still stores the name of the S-CSCF that was used by 
the UE last time", the HSS returns " thQ name of the S-CSCF that has served the UE" to the I- 
CSCF": and fii^ when "the H SS has stored the name of the S-CSCF that has served or is 
serving the UE and the HSS is not sxire whether it is needed for the I-CSCF to re-select an S- 
CSCF to serve the UE", the HSS retums to the I-CSCF "the name of the S-CSCF that has 
served or is serving the UE and the S-CSCF capability information set that has the capability 
to meet the most strict service subscription requirement of the UE requesting registration." 
Apparently, Bajko does not suggest all the elements of independent claim 12. 

2) Claim 12 states "if there is at least one Public User Identity of the UE requesting 
registration of which the registration status is unregistered or the registration has expired, but 
the HSS still stores the name of the S-CSCF that was used by the UE last time, or if the UE 
has been assigned an S-CSCF by the HSS as an unregistered party that is called, then said 
information needed for determining an S-CSCF comprises the name of the S-CSCF that has 
served the UE." These elements together suggest that when the registration status is 
unregistered or the registration has expired, the name of the S-CSCF that has served the UE is 
returned by the HSS to the I-CSCF if the HSS still stores the name of the S-CSCF that was 
used by the UE last time, or if the UE has been assigned an S-CSCF by the HSS as an 
unregistered party that is called. Bajko merely describes providing the name of the S-CSCF 
in the existing registration. It, however, fails to suggest any solution in the situation that the 
registration status is unregistered or the registration has expired as recited in claim 12. 

3) Claim 12 states "if HSS has stored the name of the S-CSCF that has served or is 
serving the UE and the HSS is not sure whether it is needed for the I-CSCF to re-select an S- 
CSCF to serve the UE, then said information needed for determining an S-CSCF comprises 
the name of the S-CSCF that has served or is serving the UE and the S-CSCF capability 
information set that has the capability to meet the most strict service subscription requirement 
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of the UE requesting registration." Accordingly, claim 12 sets forth a method step where the 
HSS returns to the I-CSCF the name of the S-CSCF that has served or is serving the UE and 
the S-CSCF capability information set that has the capability to meet the most strict service 
subscription requirement of the UE requesting registration, when the HSS has stored the 
name of the S-CSCF that has served or is serving the UE and the HSS is not sure whether it is 
needed for the I-CSCF to re-select an S-CSCF to serve the UE . Bajko makes no mention of 
these claim features. In addition, in claim 12, besides the name of the S-CSCF that has 
served or is serving the UE, the information needed for determining an S-CSCF further 
includes the S-CSCF capability information set that has the capability to meet the most strict 
service subscription requirement of the UE requesting registration, Bajko clearly fails to 
describe such information needed for determining an S-CSCF, including the name of the S- 
CSCF that has served or is serving the UE and the S-CSCF capability information set that has 
the capability to meet the most strict service subscription requirement of the UE requesting 
registration as set forth in claim 12. 

4) Claim 12 states "if there is no assigned S-CSCF that has served the UE stored in 
the HSS, then said information needed for determining an S-CSCF comprises the S-CSCF 
capability information set that has the capability to meet the most strict service subscription 
requirement of the UE requesting registration." Claim 12 thus sets forth a step of the HSS 
returning to the I-CSCF the S-CSCF capability information set that has the capability to meet 
the most strict service subscription requirement of the UE requesting registration when there 
is no assigned S-CSCF that has served the UE stored in the HSS. Bajko clearly fails to 
suggest these claim features either. 

For the aforementioned reasons, the applicants submit that Bajko fails to anticipate 
independent claim 12. 

As for dependent claims 2-3, 5, 7, 10, 14, and 16, without conceding the Office 
action's assertion, the applicants point out that these claims depend from independent claims 
1 or 12 and therefore include all of the limitations of the independent claims. Therefore, the 
applicants respectfully submit that these dependent claims are patentably distinguishable 
from Bajko for at least the reasons discussed above and request the Examiner withdraw the 
rejections. 
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Rejections Under 35 U.S,C, S 103 

Dependent claims 4, 6, 8 and 13 stand rejected under 35 U.S.C. § 103(a) as being 
unpatentable over Bajko in view of Phan Anh (US Application Publication 2004/0185848 Al) 
and claims 9, 15 and 17 stand rejected under 35 U.S.C. § 103(a) as being unpatentable over 
Bajko in view of Flykt (US Patent No. 7366303 B2). 

The applicants respectfully traverse these rejections. As discussed above, Bajko fails 
to disclose every element of independent claims 1 and 12. Neither Phan Anh nor Flykt make 
up the deficiencies of Bajko, because they also fail to teach those features missing from 
Bajko. Since claims 4, 6, 8, 9, 13, 15, and 17 depend, directly or indirectly, from independent 
claims 1 or 12, they include all of the limitations of the independent claims. Therefore, the 
applicants respectfully submit that dependent claims 4, 6, 8, 9, 13, 15, and 17 are patentably 
distinguishable from any combination of Bajko, Phan Anh, and Flykt for at least the reasons 
discussed above and request the Examiner withdraw the rejections. 

Conclusion 

A prompt indication of allowability of all claims 1-10 and 12-17 is earnestly solicited. 
Should the examiner wish to discuss the foregoing, or any matter of form in an effort to 
advance this application toward allowance, he is urged to telephone the undersigned at the 
indicated number. 



Respectfully submitted. 




LEYDIG, VOIT & MAYER, LTD. 
Two Prudential Plaza, Suite 4900 



1 80 North Stetson Avenue 
Chicago, Illinois 60601-6731 
(312) 616-5600 (telephone) 
(312) 616-5700 (facsimile) 



Date: September 29, 2009 
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